Repository navigation
fix(build-record): mark a build's edit in another repository, never refuse it - #134
Merged
Merged
Conversation
…efuse it - Let a Write, Edit or NotebookEdit in another repository through during an open build, marking the build once per repository - Write the mark again when it does not read back, as after a log line cut short - Summarize every marked repository as `edited <repo>` - Drop implement-change's Stop / Go on unrecorded question - Update the README, contracts and design notes Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
hooks/build-record.shrecords what animplement-changebuild did, andpr-createprints it as the PR's Already checked block. The record lives in the.review/of the repository the session started in, so an edit in another repository would count that work as this build's. The hook handled that by refusing the first such edit and having the model ask the person to Stop or Go on unrecorded. That stop interrupted cross-repository work mid-build (for example, a libera_cdk session that also had to change libera_utils), often after the person had already said the work belonged in that session, and the answer was always to go on. Once this merges, the hook marks the build and lets the edit through, so the block readsGates: not recorded, this session also edited <repo> …and nothing stops.implement-changeno longer asks the question either: it says once that the change is in another repository and goes on.Two smaller changes ride along:
tried to edit <repo>form had no producer once nothing is refused, so every marked repository readsedited <repo>. No script parses that form, and the block's version is unchanged, as when the form was added.Guarded by the cross-repository section of
tests/test_build_record.sh: an edit there passes with no output and keeps the lock, one mark per repository, a refused mark from an older log counts as a mark, and a mark after a cut-short line is written again.Origin: the maintainer's complaint in a working session that the build hook's cross-repository Stop / Go on unrecorded question halts work and is always answered "go on"
Sandbox: none; no scenario edits a second repository, so the change rests on
tests/test_build_record.shCanary: none yet
🤖 Generated with Claude Code. AI assistance level: 5/5 (not read by a person).